Knowledge based electronic clinical record for dentistry

ABSTRACT

The present invention relates to an electronic records management system. More specifically, the present invention is a comprehensive knowledge based clinical records management solution that encompasses the need for accurate records, while reducing the time and effort required to enter complete and accurate information.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to an electronic records managementsystem. More specifically, the invention relates to electronic recordsmanagement systems generally in the field of medical records, and hasaspects that specifically relate to dental medical records.

2. Description of the Related Art

The World Health Organization defines Dentistry as ‘the science and artof preventing, diagnosing and treating diseases, injuries andmalformations of the teeth, jaws and mouth.’ Problems with teeth andgums have troubled humans for thousands of years. Ancient Egyptianmedical texts, dating back to 3500 BC, refer to toothaches. Hesi-Re, anEgyptian who lived around 3000 BC, is the earliest dentist known byname. Organized dentistry began when the world's first dental school,the Baltimore College of Dental Surgery, opened in Baltimore, Md. in1840.

The first business computer was used for the first time in 1951 to takethe United States census. By 1962, there were over 40,000 businesscomputers in the United States. In just one more year, that numberdoubled. Since that time businesses have utilized computers in a varietyof ways. One major computer use for many businesses is recordsmanagement. Obviously, keeping complete and accurate records andmaintaining them securely is vital to all medical professionals. Over160 dental practices lost all of their physical patient records as aresult of Hurricane Katrina. This loss could have been prevented byoffsite secure storage of electronic copies of records. Electronicrecords management has eclipsed physical records management as thepreferred option for most practitioners. Ever-evolving complianceregulations and statutes have also increased interest in electronicrecords management systems among businesses including dental practices.Dental practitioners constantly strive to make their offices moreefficient, saving time, effort and money. Having a comprehensiveelectronic system in place where copious patient records can bemaintained and easily accessed makes the practice run more efficientlyand helps provide patients the best possible care.

According to the American Dental Association (ADA), the primaryprofessional organization of dentists, there are more than 175,000licensed dentists practicing in the United States today. Nine out of tenare in private practice. Making accurate and complete record entries isa crucial area of professional responsibility. A record entry must bemade for every patient interaction that occurs, from a missedappointment to a final cementation and including all relevant dataregarding each patient's treatment. Dental practitioners are constantlystriving for ways to achieve higher quality, more efficientcommunication, reduced administrative time and costs, and to reduce theburden of keeping up with patient charts, dictation and correspondence.Many dentists are converting to digital recordkeeping in their quest tosave time, paper and money while maintaining accuracy.

There are many important reasons for keeping thorough, accurate records.First, it helps facilitate better patient care. Referring todescriptions of prior patient care helps the dentist evaluate theeffectiveness of care. Second, a patient may be treated in severaldifferent clinics. To ensure the smooth transition of a patient fromclinic to clinic, information must be easily transmittable. The patientrecord is often the sole source of vital facts concerning patienttreatment status. Third, the patient record is the mechanism by whichinsurance claims are filled out, itemized statements prepared, andcharges are reviewed for accuracy. In order to determine chargesaccurately, the details of each procedure must be well documented.Fourth, the efficient use of the time of all involved in patient care isyet another important reason for making complete and legible recordentries.

Previous versions of the records management system detailed belowreduced the effort required in creating patient charts by utilizing aglossary of medical and/or dental specific terms, organized in anexpandable/collapsible hierarchical tree. The user could select a termor branch node, with each branch node being expandable to reveal furtherterms or nodes for selection. The user could then select a desired termwithout further data entry. While this hierarchical structure providedbenefits for the dental practitioner, the inventor of this systemcontinued development of the system to further enhance the interactionwith the dental practitioner.

SUMMARY OF THE INVENTION

The present invention is a clinical records management system thatencompasses the need for comprehensive, accurate records, while reducingthe time and effort required to record complete and accurateinformation. While the application uses terminology common to dentistry,the organization of terminology into procedure specific digital forms isunique and constitutes a domain specific knowledge base. Thisorganization constitutes algorithms which are also domain specificknowledge. Additionally, making selections from these forms and havingthe application automatically generate from that the notes whichconstitute the clinical patient records The present invention employs aconfigurable computer graphical user interfaces (GUI) to effectuate anefficient and smooth flow of data entry which can then be viewed invarious ways or converted into a variety of documents for sharingpatient clinical information with other treating healthcare providers.Additionally, the application knowledge base includes a variety ofdocuments to aid in communications with patients: procedure specificinformed consents, procedure specific pre-operative and post-operativepatient instructions and instructions for taking specific medicationsincluding descriptions of possible side effects, warnings and risks.There are at least four different aspects of the present invention andeach is discussed in detail below in relation to embodiments of theinvention.

One aspect of the present invention is the Main User Interface (UI). TheMain UI consists of eight interrelated, editable areas. The Main UI'sopening view consists of a thumbnail view of several categories of data,along with a patient identifier data area and a list of prior sessions(entries) area. The thumbnail views are ‘window-panes’ each of which canbe expanded to fill the entire main window so associated data can bemore easily viewed and/or edited. The categories may include a dentalchart area, planned treatment area, a list of prior documents generatedarea, a list of patient alerts & modifiers area, a summary of thepatient's general health area and a medications prescribed area. Thesecategories of information to be viewed in this opening UI may beconfigured by the end-user.

Another aspect of the present invention relates to Procedure SpecificForms which provide the user with the ability to create chart entries byselecting items from a form instead of typing. These forms are presentin several embodiments of the invention. The user makes selections fromcheckboxes, dropdown lists and multiple choice lists resulting in acompound template made up of the specific selected items. Theapplication then filters the entire procedure-specific form for thoseitems selected by the user and creates a document describing whatoccurred during a particular patient session. This component allows theuser to easily generate readable output based on user selections that isthen copied to a separate word processing program and converted into anoutline formatted document, thus reducing the number of keystrokes (andmouse clicks) necessary to create the desired output.

A further aspect of the present invention is the mechanism for building‘Procedure Specific Template/Forms. ‘Template/Forms’ are electronic(digital) ‘forms’ that contain multiple Data Fields specific to aparticular procedure or patient-related event. Using a domain specificknowledge base, a user can create these electronic forms each of whichcontains all areas of information pertinent to the procedure beingdescribed as well as all of the possible iterations for each of thesteps in the procedure. These complex forms are sub-divided intosections by ‘Tabs’ (pages). Selection is made by either checking itemsassociated with Checkboxes, DropDown List boxes or Multiple Choice Listboxes, as well as a variety of custom controls.

Another aspect of the present invention relates to the AnesthesiaRecord. The standard of care for patients receiving conscious sedation,deep sedation or general anesthesia in a dental environment calls forthe documentation of drugs, gases and other agents administered as wellas the patient's vital signs and oxygen saturation during anesthesia.While local anesthesia is the most common form of pain control used bygeneral dentists, sedation, analgesia and general anesthesia are taughtin most dental specialty residencies and are regularly used by dentalspecialists in practice. Therefore, an anesthesia record is asignificant component of an electronic dental patient record. Theanesthesia record in this application is unique in that it containsareas of information not included in other dental EMR's: pre-anesthesiaphysical evaluation, validation of equipment operation and supplies ofgases, a description of the method of administration, the airwaymanagement, the agents administered, the vital signs and thepre-discharge status of the patient. All of these elements are importantto assuring a safe and conservative anesthesia experience for thepatient. Furthermore, the depth of documentation affords thepractitioner of better risk management. Additionally, the entry of vitalsigns (blood pressure, pulse, oxygen saturation of the blood) may beautomatically recorded directly from monitoring devices thus eliminatingerrors in entry.

Another aspect of the present invention relates to a unique set of dataand display (UI) known as the ‘PerioProfile.’ This UI allows for thecollection and display of more elements of data relevant to the extentof disease as well as evidence of current disease (inflammatory)activity. In addition to the data values collected and included on atraditional periodontal chart, the PerioProfile can collect andsimultaneously display data on signs of inflammatory activity bycalculating and displaying indices for ‘Bleeding’ and ‘Exudate’activity; collect and display data on a patient's plaque controleffectiveness (a ‘Plaque Score’), and other strategic items of dentaland periodontal morphologic data pertinent to periodontal evaluation.Alphanumeric data is displayed in a ‘spreadsheet’ format so that datafor a specific site can be readily reviewed by scanning down a verticalcolumn. Additionally, this same data is displayed graphically aroundgraphics of individual teeth and implants and can include an overlay ofperiodontal supporting bone and gingiva to show the relationship betweendata items and these anatomic structures. This display of graphicalperiodontal data can be viewed with overlays of supporting bone and orgingiva. This comprehensive spreadsheet and graphical view ofperiodontal data including relationships with alveolar bone and gingivais a unique design feature of this application.

BRIEF DESCRIPTION OF THE DRAWINGS

The above mentioned and other features and objects of this invention,and the manner of attaining them, will become more apparent and theinvention itself will be better understood by reference to the followingdescription of an embodiment of the invention taken in conjunction withthe accompanying drawings, wherein:

FIG. 1 is a schematic diagrammatic view of the clinical recordsmanagement system according to one embodiment of the present invention.

FIG. 2 is a screenshot view of the main graphical user interface of oneembodiment of the present invention.

FIG. 3 is a screenshot window pane view of the Patient Identifier andSessions areas of FIG. 2.

FIG. 4 is a screenshot window pane view of the Dental Chart area of FIG.2.

FIG. 5 is a screenshot window pane view of the Planned Treatment area ofFIG. 2.

FIG. 6 is a screenshot window pane view of the Alerts & Modifiers areaof FIG. 2.

FIGS. 7A and 7B are screenshot window pane views of the General HealthSummary area of FIG. 2.

FIG. 8 is a screenshot window pane view of the Prescribed Medicationsarea of FIG. 2

FIGS. 9A-9D are screenshot window pane views of the Anesthesia Recordpage according to another embodiment of the present invention.

FIG. 10 is a screenshot view of the Vital Signs page relating to theAnesthesia Record page of FIG. 9.

FIG. 11 is a schematic diagram of the knowledge base feature in oneembodiment of the present invention.

FIGS. 12A-12D are screenshot views of a periodontal charting spreadsheetscreen relating to the Dental Chart of FIG. 4.

FIGS. 13A and 13B are screenshot views of a periodontal charting inputand display relating to the Dental Chart of FIG. 4 according to oneembodiment of the present invention.

FIG. 14 is a schematic relational diagram of the session entries of FIG.3.

FIG. 15 is a screenshot view of a Connective Tissue Graph session windowaccording to one embodiment of the present invention.

FIG. 16 is a screenshot view of a Dentoalveolar Examination window paneaccording to one embodiment of the present invention.

FIG. 17 is a plan view of a Reconstructive Implant, Periodontal andOrofacial Surgery bullet point report letter generated by one embodimentof the present invention.

Corresponding reference characters indicate corresponding partsthroughout the several views. Although the drawings representembodiments of the present invention, the drawings are not necessarilyto scale and certain features may be exaggerated in order to betterillustrate and explain the present invention. The exemplification setout herein illustrates an embodiment of the invention, in one form, andsuch exemplifications are not to be construed as limiting the scope ofthe invention in any manner.

DESCRIPTION OF EMBODIMENTS OF THE PRESENT INVENTION

The embodiment disclosed below is not intended to be exhaustive or limitthe invention to the precise form disclosed in the following detaileddescription. Rather, the embodiment is chosen and described so thatothers skilled in the art may utilize its teachings.

The detailed descriptions which follow are presented in part in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory representing alphanumeric characters or otherinformation. These descriptions and representations are the means usedby those skilled in the art of data processing arts to most effectivelyconvey the substance of their work to others skilled in the art.

An algorithm is here, and generally, conceived to be a self-consistentsequence of steps leading to a desired result. These steps are thoserequiring physical manipulations of physical quantities. Usually, thoughnot necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared, and otherwise manipulated. It proves convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, symbols, characters, display data, terms, numbers, or thelike. It should be borne in mind, however, that all of these and similarterms are to be associated with the appropriate physical quantities andare merely used here as convenient labels applied to these quantities.

Some algorithms may use data structures for both inputting informationand producing the desired result. Data structures greatly facilitatedata management by data processing systems, and are not accessibleexcept through sophisticated software systems. Data structures are notthe information content of a memory; rather they represent specificelectronic structural elements which impart a physical organization onthe information stored in memory. More than mere abstraction, the datastructures are specific electrical or magnetic structural elements inmemory which simultaneously represent complex data accurately andprovide increased efficiency in computer operation.

Further, the manipulations performed arc often referred to in terms,such as comparing or adding, commonly associated with mental operationsperformed by a human operator. No such capability of a human operator isnecessary, or desirable in most cases, in any of the operationsdescribed herein which form part of the present invention; theoperations are machine operations. Useful machines for performing theoperations of the present invention include general-purpose digitalcomputers or other similar devices. In all cases the distinction betweenthe method operations in operating a computer and the method ofcomputation itself should be recognized. The present invention relatesto a method and apparatus for operating a computer in processingelectrical or other (e.g., mechanical, chemical) physical signals togenerate other desired physical signals.

The present invention also relates to an apparatus for performing theseoperations. This apparatus may be specifically constructed for therequired purposes or it may comprise a general-purpose computer asselectively activated or reconfigured by a computer program stored inthe computer. The algorithms presented herein are not inherently relatedto any particular computer or other apparatus. In particular, variousgeneral-purpose machines may be used with programs written in accordancewith the teachings herein, or it may prove more convenient to constructmore specialized apparatus to perform the required method steps. Therequired structure for a variety of these machines will appear from thedescription below.

The present invention deals with ‘object-oriented’ software, andparticularly with an ‘object-oriented’ operating system. The‘object-oriented’ software is organized into ‘objects’, each comprisinga block of computer instructions describing various procedures(‘methods’) to be performed in response to ‘messages’ sent to the objector ‘events’ which occur with the object. Such operations include, forexample, the manipulation of variables, the activation of an object byan external event, and the transmission of one or more messages to otherobjects.

Messages are sent and received between objects having certain functionsand knowledge to carry out processes. Messages are generated in responseto user instructions, for example, by a user activating an icon with a‘mouse’ pointer generating an event. Also, messages may be generated byan object in response to the receipt of a message. When one of theobjects receives a message, the object carries out an operation (amessage procedure) corresponding to the message and, if necessary,returns a result of the operation. Each object has a region whereinternal states (instance variables) of the object itself are stored andwhere the other objects are not allowed to access. One feature of theobject-oriented system is inheritance. For example, an object fordrawing a ‘circle’ on a display may inherit functions and knowledge fromanother object for drawing a ‘shape’ on a display.

A programmer ‘programs’ in an object-oriented programming language bywriting individual blocks of code each of which creates an object bydefining its methods. A collection of such objects adapted tocommunicate with one another by means of messages comprises anobject-oriented program. Object-oriented computer programmingfacilitates the modeling of interactive systems in that each componentof the system can be modeled with an object, the behavior of eachcomponent being simulated by the methods of its corresponding object,and the interactions between components being simulated by messagestransmitted between objects. Objects may also be invoked recursively,allowing for multiple applications of an objects methods until acondition is satisfied. Such recursive techniques may be the mostefficient way to programmatically achieve a desired result.

An operator may stimulate a collection of interrelated objectscomprising an object-oriented program by sending a message to one of theobjects. The receipt of the message may cause the object to respond bycarrying out predetermined functions which may include sendingadditional messages to one or more other objects. The other objects mayin turn carry out additional functions in response to the messages theyreceive, including sending still more messages. In this manner,sequences of message and response may continue indefinitely or may cometo an end when all messages have been responded to and no new messagesare being sent. When modeling systems utilizing an object-orientedlanguage, a programmer need only think in terms of how each component ofa modeled system responds to a stimulus and not in terms of the sequenceof operations to be performed in response to some stimulus. Suchsequence of operations naturally flows out of the interactions betweenthe objects in response to the stimulus and need not be preordained bythe programmer.

Although object-oriented programming makes simulation of systems ofinterrelated components more intuitive, the operation of anobject-oriented program is often difficult to understand because thesequence of operations carried out by an object-oriented program isusually not immediately apparent from a software listing as in the casefor sequentially organized programs. Nor is it easy to determine how anobject-oriented program works through observation of the readilyapparent manifestations of its operation. Most of the operations carriedout by a computer in response to a program are ‘invisible’ to anobserver since only a relatively few steps in a program typicallyproduce an observable computer output.

In the following description, several terms which are used frequentlyhave specialized meanings in the present context. The term ‘object’relates to a set of computer instructions and associated data which canbe activated directly or indirectly by the user. The terms ‘windowingenvironment’, ‘running in windows’, and ‘object oriented operatingsystem’ are used to denote a computer user interface in whichinformation is manipulated and displayed on a video display such aswithin bounded regions on a raster scanned video display. The terms‘network’, ‘local area network’, ‘LAN’, ‘wide area network’, or ‘WAN’mean two or more computers which are connected in such a manner thatmessages may be transmitted between the computers. In such computernetworks, typically one or more computers operate as a ‘server’, acomputer with large storage devices such as hard disk drives andcommunication hardware to operate peripheral devices such as printers ormodems. Other computers, termed ‘workstations’, provide a user interfaceso that users of computer networks can access the network resources,such as shared data files, common peripheral devices, andinter-workstation communication. The computers have at least oneprocessor for executing machine instructions, and memory for storinginstructions and other information. Many combinations of processingcircuitry and information storing equipment are known by those ofordinary skill in these arts. A processor may be a microprocessor, adigital signal processor (‘DSP’), a central processing unit (‘CPU’), orother circuit or equivalent capable of interpreting instructions orperforming logical actions on information. Memory includes both volatileand non-volatile memory, including temporary and cache, in electronic,magnetic, optical, printed, or other format used to store information.Users activate computer programs or network resources to create‘processes’ which include both the general operation of the computerprogram along with specific operating characteristics determined byinput variables and its environment.

The terms ‘desktop’, ‘personal desktop facility’, and ‘PDF’ mean aspecific user interface which presents a menu or display of objects withassociated settings for the user associated with the desktop, personaldesktop facility, or PDF. When the PDF accesses a network resource,which typically requires an application program to execute on the remoteserver, the PDF calls an Application Program Interface, or ‘API’, toallow the user to provide commands to the network resource and observeany output. The term ‘Browser’ refers to a program which is notnecessarily apparent to the user, but which is responsible fortransmitting messages between the PDF and the network server and fordisplaying and interacting with the network user. Browsers are designedto utilize a communications protocol for transmission of text andgraphic information over a worldwide network of computers, namely the‘World Wide Web’ or simply the ‘Web’. Examples of Browsers compatiblewith the present invention include the Internet

Explorer program sold by Microsoft Corporation (Internet Explorer is atrademark of Microsoft Corporation), the Opera Browser program createdby Opera Software ASA, or the Firefox browser program distributed by theMozilla Foundation (Firefox is a registered trademark of the MozillaFoundation). Although the following description details such operationsin terms of a graphic user interface of a Browser, the present inventionmay be practiced with text based interfaces, or even with voice orvisually activated interfaces, that have many of the functions of agraphic based Browser.

Browsers display information which is formatted in a StandardGeneralized Markup Language (‘SGML’) or a HyperText Markup Language(‘HTML’), both being scripting languages which embed non-visual codes ina text document through the use of special ASCII text codes. Files inthese formats may be easily transmitted across computer networks using ahypertext transfer protocol (‘HTTP’) or a secure HTTP (‘SHTTP’),including global information networks like the Internet, and allow theBrowsers to display text, images, and play audio and video recordings.The Web utilizes these data file formats to conjunction with itscommunication protocol to transmit such information between servers andworkstations. Browsers may also be programmed to display informationprovided in an eXtensible Markup Language (AMU) file, with XML filesbeing capable of use with several Document Type Definitions (‘DTD’) andthus more general in nature than SGML or HTML. The XML file may beanalogized to an object, as the data and the stylesheet formatting areseparately contained (formatting may be thought of as methods ofdisplaying information, thus an XML file has data and an associatedmethod).

The terms ‘personal digital assistant’ or ‘PDA’, as defined above, meansany handheld, mobile device that combines computing, telephone, fax,e-mail and networking features. The terms ‘wireless wide area network’or ‘W WAN’ mean a wireless network that serves as the medium for thetransmission of data between a handheld device and a computer. The term‘synchronization’ means the exchanging of information between a handhelddevice and a desktop computer either via wires or wirelessly.Synchronization ensures that the data on both the handheld device andthe desktop computer are identical.

In wireless wide area networks, communication primarily occurs throughthe transmission of radio signals over analog, digital cellular, orpersonal communications service (‘PCS’) networks. Signals may also betransmitted through microwaves and other electromagnetic waves. At thepresent time, most wireless data communication takes place acrosscellular systems using second generation technology such ascode-division multiple access (‘CDMA’), time division multiple access(‘TDMA’), the Global System for Mobile Communications (‘GSM’), personaldigital cellular (‘PDC’), or through packet-data technology over analogsystems such as cellular digital packet data (CDPD’) used on the AdvanceMobile Phone Service (‘AMPS’).

The terms ‘wireless application protocol’ or ‘WAP’ mean a universalspecification to facilitate the delivery and presentation of web-baseddata on handheld and mobile devices with small user interfaces.

The term ‘Session’ means a specific patient related encounter. Somesessions will be related to a patient visit to the dentist's office.Others sessions will be to document something else related to thepatient (for example, phoned in a prescription, phone call to thepatient, documents mailed to the patient, etc.).

The term ‘Procedure’ relates to a specific patient related event such asa Periodontal Exam or an Implant Surgery. A procedure is based on a‘Type’ and a ‘Sub-specialty.’

The term ‘Type’ means the type of process being performed and documentedduring a particular patient session. For example, Exam, Treatment,Progress, Outcomes, etc.

The term ‘Template’ means an electronic (digital) ‘form’ which containsmultiple Data Fields specific to a particular procedure or process.Templates are based on a specific combination of a ‘Type’ and a‘Sub-specialty.’ A Template may be an editable document having certaininformation already present and predefined sections for data entry, ormay be a rule based document generator as described in more detailbelow.

The terms ‘Record’ and ‘Chart’ relate to a patient's clinicaldocumentation (i.e., the clinical record or the clinical chart).

The present invention generally involves a knowledge based clinicalrecords management solution which employs a configurable computergraphical user interface (GUI) to effectuate an efficient and smoothflow of data from the end-user to the clinical records. The embodimentsof the present invention provide for the creation, management, use andsharing of clinical patient information in a dental practice, althoughmany aspects of the present invention are applicable in the generalmedical field. There are at least four aspects of the present inventionand each is discussed in detail below in discussions of the associatedembodiments of the invention. FIG. 1 depicts a schematic representationof clinical records management system 102. Main User Interface (UI) 104is capable of obtaining and displaying patient-related from a pluralityof databases. Main UI also accesses non-patient related data that isneeded to operate a Dental Office. Dental Office Systems 130 may includeBilling 132, Scheduling 134 and other systems 136 that may be used inthe office of a dental practice. Records Management System 102 includesMain UI 104 which reads and updates patient data in Dental Specificdatabase 120, General Patient database 122 and Anesthesia Recorddatabase 124. User input is facilitated and made easier using KnowledgeBase 108, discussed in detail below. Records Management System 102 maybe implemented as a stand alone program, including all the programmingnecessary to interact with databases 120, 122, and 124. Alternatively,Records Management System 102 may interact with existing databaseprograms that manage databases 120, 122, and 124.

One embodiment of the present invention includes Main UI 104 which isdepicted in FIG. 2. Main UI 104 is divided into vertical columns on thecomputer screen which includes, in this exemplary embodiment, an upperbox in the left most column having patient ID information. Below that isa window pane which has a list of sessions for the patient, as sessionsare described in greater detail with regards to FIGS. 3 and 14. To theright of this is the ‘Main Window’ for the application. These thumbnailviews are ‘window-panes,’ each of which can be expanded to fill theentire main window so that they can be more easily viewed or read. TheMain UI, in this exemplary embodiment, consists of eight areas. Theexact number of areas, and the selection and arrangement of such areas,may be modified for accommodating various desired data displays and/orhardware configurations of the displaying device. For example,additional data viewing may be provided depending on the amount andcharacter of patient data maintained by records management system 102.Alternatively, the shape and size of the areas may be adapted to smallerscreens generally available on hand-held devices or to larger displayscreen than conventionally used in a dental practitioner's office.

Patient identifier area 1 comprises, in the exemplary embodiment,patient-related data as depicted more particularly in FIG. 3. The datamay include, but is not limited to, full legal name, address, othercontact information (e.g., phone, mobile phone, instant messaging,e-mail), date of birth, age in years, primary health care provider(dentist and/or doctor), social security number (SSN), health insuranceinformation (policy issuer and policy number), name of the patient'sprimary care dentist, and a photo or portrait of the patient. For HealthInsurance Portability and Accountability Act (HIPAA) compliance, the SSNis not readily viewable on the screen and only displays in a ‘popup’when the mouse ‘hovers’ over the ‘SSN’ icon. The exact informationdisplayed may be configured by the user for personal or officepreferences and procedures.

Shown in FIG. 2, Sessions List area 2 includes a list of prior dataentries relating to treatment sessions of the patient prior to anycurrent windows. FIG. 3 shows this in greater detail, with the lowerportion of the window pane as including a list of sessions. Each sessionis a collection of information about a particular patient visit. Theselection of a particular session results in the population of the otherwindow panes of Main UI 104. This allows the practitioner/user to viewin one screen a summary of the relevant patient data availableelectronically, and the practitioner/user may drill down any of theother window panes (as described in greater detail below) to obtain thefull data from any of these summaries. Further, the practitioner/usermay initiate a new session. When a new session is initiated, the datarecord or object associated with the new session inherits theinformation from the immediately prior session, allowing thepractitioner/user to avoid having to enter duplicative data, so thatonly the entry of new data and/or the deletion of old data is required.In the exemplary embodiment, only session information in the currentsession may be edited and prior session information is available inread-only mode. However, it is possible to configure the software toprovide permission based editing features, so that a user and/orsuper-user may be able to modify certain prior session data.

Dental Chart area 3, shown in FIG. 2 and particularly in FIG. 4,includes an occlusal view of the teeth in the upper (maxillary) andlower (mandibular) arches (jaws). Occlusal relates to the grinding orbiting surface of a tooth. Dental chart area 3 makes use of color-codingto depict missing teeth, the presence of crowns, implants and otherdental treatments. Dental Chart area 3 gives the end-user a quick, yetinformative way of viewing the patient's teeth. In addition, moredetailed periodontal charting may be invoked from this area 3 asdescribed in greater detail below in the discussion of FIGS. 12 and 13.

Treatment Planned area 4, depicted in FIG. 2 and particularly in FIG. 4,lists treatments that are planned for the patient and may make use ofcolor-coding to show which treatments had been carried out and whichtreatments still need to be carried out. Color-coding allows the data tobe presented in a way that allows the end-user an easy way to quicklydetermine what planned treatments have been carried out and which arestill needed. Billing codes and descriptions of all parts of thetreatment plan that are billable items are passed to Dental OfficeSystems 130. This eliminates duplicate entries and the possibility oferrors.

Depicted in FIG. 2, Treatment area 5 includes a list of prior patientencounters that had been documented in the patient's clinical record(treatments and other patient interaction events relevant to a treatmentplan). The display, in this exemplary embodiment, is by date of thetreatment. Double-clicking on any treatment date brings up the detailsof that treatment in either of the following ways: (a) the narrativenotes as displayed below in section; or (b) the form used to enter notesallowing modification of the notes. The display, in another embodiment,may be by date and title of the treatment.

Alerts & Modifiers area 6 of FIG. 2 is shown more particularly in FIG.6. A&M area 6 includes listings of the current significant risk factorsor modifiers that had been added to the patient's record that should be‘flagged’ and brought to the practitioner's attention because they wereassociated with highlighted risk or required specific needs whenexamining or treating the patient. The contents of A&M 6 displayrecently updated listings and the contents of this category arcautomatically copied forward from the prior session as soon as a newsession is created. This helps provide the best patient care by ensuringthe practitioner does not miss any significant risk factors ormodifiers.

General Health Summary area 7 of FIG. 2 is depicted in particularity inFIGS. 7A and 7B. General Health Summary area 7 of FIG. 7A includescurrent health status of the patient including terms entered from theglossary (long-term medical conditions which are still of significantconcern, allergies, medications, etc.). General Health Summary area 7displays updated listings and contents that may be automatically copiedforward from the prior session as soon as a new session is created.Current medications prescribed by others (medical doctors, etc.) arealso shown in General Health Summary area 7. When expanded, as depictedin FIG. 7B, the full General Health Summary is available for review andediting. In this exemplary embodiment, tabs are provided for thefollowing items: Current Medications, Allergies, Vital Signs, DrugIdiosyncrasies, Medical History, Personal-Social Conditions or Habits,A.S.A. Classification.

Medications Prescribed area 8 of FIG. 2 is depicted in particularity inFIG. 8. Medications Prescribed area 8, as particularly shown in FIG. 8,lists medications (prescribed and over-the-counter) that may have beenprescribed for the patient by anyone in the end-user's practice.Medications Prescribed area 8 includes a listing of prescribed itemswhich are, in the exemplary embodiment, sorted by date. Each item is asummary of an underlying prescription record, which by thepractitioner/user activating an item a more detailed record associatedwith the particular prescription.

Records Management System 102 thus includes a database comprised of acollection of chart entries representing the patient's clinical dentalhealth history record. These records may be organized into rows andcolumns referencing the totality of the patient clinical dental healthhistory. Chart entries are collected into charts. Each chart mayrepresent a particular aspect of a session between the patient and thepractitioner.

Yet another novel aspect of this invention is the concept of a chartview configuration. Chart views define the patient chart content andorganization used for viewing or printing. These include specializedreports, letters, presentations, and statistical graphs. Chart views arepre-defined by a knowledge base for immediate use by a practitioner, andare fully configurable for customization if desired. Chart views may beused to define specific data elements of the patient chart (columns),filter for specific data (queries), and organize data into groups, orderdata (sort), and dynamically format data (fonts/color/style). Anycombination of information may be obtained using configurable chartviews. Configuring each Patient Chart is optional, and the practitioneror administrator may specify certain default views for general use.

The specific types of chart view configurations are provided, in theexemplary embodiment, as Chart Filter(s), Chart Graph(s) or ChartReport(s). Chart Filters allow the user to quickly find specific chartentries by selecting a term from a listing of categories orsub-categories, and then activating the chart filter (view) mode. Thisfeature adds the ability to filter the patient charts on multiplecategory terms at the same time as well as applying chart views tobetter organize the result presentation.

Chart Graphs supports the ability to view patient chart information inmany different graphical formats. The user may combine Chart Filterswith Chart Graphs to produce trend information on just about anythingrelated to the patient chart records.

Chart Reports are based on similar principles as Chart Filters. Anypatient chart information may be sent to a local printer for reportgeneration using all of the same configuration features offered by chartviews. A difference between a chart view and a chart report is thatgrouped terms are organized as blocks and sub-blocks in the reportoutput. Additionally, any application display may be sent to the localprinter using the built-in web browser print function.

The view configuration provides dynamic formatting to a particular view(i.e. Chart Filter, Chart Graph, Chart Report). For example a particularview may highlight terms that are more important than other terms suchas medical alerts or a particular treatment plan as differentiated fromthe actual treatment provided. This is called dynamic formatting becauseeach column or data item is evaluated against specific configurationcriteria and configuration formatting styles are applied to the data asit is displayed in a current view. The formatting styles include font,coloration, and other types of text and graphics formatting. In this waythe practitioner or administrator of this invention can customize howthe Patient Chart is displayed according to his/her own preferences.Dynamic value based formatting configurations can be defined for eachpatient view listing rows or graphics for patient clinical chart historywith value based formatting styles.

The view configuration is used to present information according to viewconfiguration rules for (Reports, Graphic Charts, and Letters), andtakes the dynamic information returned from the view configuration andinputs into the predefined presentations. In the exemplary embodiment,standard ‘views’ are defined in the initial setup. Thepractitioner/user, however, can add new ‘views’ to sort and view thedata from the Patient Chart(s) as s/he finds most useful. Such views maybe configured for different viewing devices, so that hand-held devicessuch as PDA and/or telephones (either cellular, radio, or VoIP) mayreceive, display, and receive input on such views. Thus, apractitioner's office may be configured to provide such views onmultiple types of devices, adapting to the style and parameters of theindividuals in the office. Thus, a practitioner might in onecircumstance view and edit a patient record in the middle of anexamination or procedure using such a hand-held device. In othercircumstances, a practitioner may use a full computer and display toexamine, make notes, and plan further procedures remotely from thepatient.

Another aspect of the present invention relates to a Dental (or Medical)Smart Procedure-Specific Forms Generator. In the exemplary embodiment,this component involves a rules-based dental record entry system inwhich the current context provides a specific template form associatedwith a selected category or sub-category. The selected template form isused to fill in data fields relating to the patient and to guide thecreation of forms narratives. After starting a new session, a dialog boxis displayed with choices of Specialty Type (‘Type’) and Sub-CategoryType (‘Sub-Category’) and depending on the Sub-category Type selected,it may include another choice: ‘Procedures’. ‘Procedures’ is selectedfrom a dropdown list that would be specific to the selected‘Sub-category.’ Appendix A provides a sample of dropdown listscontaining dental-specific terms for Types, Sub-Categories andProcedures.

The end-user is able to make multiple selections from Type ‘Specialty’,Sub-category ‘Type’ and Procedure lists resulting in a compound templatemade up of the specific items that had been selected but always in theorder of Types, Sub-categories, and then Procedures. The Smart FormGenerator filters the entire glossary and displays only those items thatpertain to the specific tasks being performed and documented during aparticular session. Each general type of form (Examination, Non-surgicalcare, Surgical care) provides a default set of tabs for individual pagesrelating to information relevant for the overall form. For example, inthe exemplary embodiment the Examination includes at least the followingtabs: Chief Complaint, History, Health Summary, Clinical Findings,Radiographic & Lab Findings, Diagnoses, and Treatment Plan. As anotherexample, the exemplary embodiment of the Non-surgical care form includesat least the following tabs: Chief Complaint, POH (personal oralhygiene), Clinical Findings, Radiographic Findings, Treatment(performed), Intra-op Findings, Local Anesthetic, Further Needs. Theexemplary embodiment of the Surgical care form includes at least thefollowing tabs: Pre-op (including Indications and Goals of theProcedure), Procedure (description), lntra-op Findings, Suturing &Coverage, Local Anesthetic, Pre-discharge Summary, and Analgesia. Thepractitioner/user may select from a brief form (standard data entry),comprehensive form (enhanced standard data entry), and a customized form(specific user defined selection of possible data entry). Presenting thespecific terms on each page in something similar to a paper-based formonly requires mouse clicking on check boxes, selecting a single itemfrom a dropdown list or selecting multiple items from an options list.Unusual comments arc typed into a text field.

One example present in FIG. 15 and Appendix A involves a scenario inwhich Surgical care is selected as the category of the form,and-Periodontal is then selected as the Sub-Category. A list ofProcedures for the selected Type/Sub-Category is then displayed. Forexample, ‘Connective Tissue Graft’ may be selected to lead the user tothe template shown in FIG. 15 and Appendix B. In particular, FIG. 15depicts the particular screen displayed to the practitioner/user whenthe tab “Site Prep Harvest & Placement” is activated. Template forms arediscussed below in relation to a third component of an embodiment of thepresent invention.

A further aspect of the present invention involves an Input Mechanismfor Building Session Content from ‘Templates/Forms.’ After selecting aType/Sub-Category/Procedure combination, a particular Template isdisplayed for the user. ‘Templates’ are electronic forms that containmultiple data fields specific to a particular procedure or process,typically in a screen having multiple tabs and data entry locations.They give a familiar look and functionality to inputting data. In oneembodiment, Templates are pre-existing documents stored in TemplateLibrary 108, which when invoked from a current session, inheriting theinformation from the patient and session. In an alternative embodiment,Templates are created dynamically based on the selected combination, aTemplate rule, and initial data entries relating to the patient and thesession. User selections define input prompts for accepting selectablepatient-related data. The user is presented terms in a template orelectronic form from which he/she will (1) click on check boxes, (2)make single selections from dropdown list boxes, (3) make multipleselections from multiple options boxes or (4) write in blank textfields. FIG. 16 shows an exemplary input screen for a procedure, in thiscase a Dentoalveolar Examination. Each form may have several tabs eachwith several data entry fields.

When the user finishes making selections from the template, he/sheclicks a button (Save) which re-compiles the selected items along withtheir appropriate parent terms to display in prose format or bulletedformat. Some or all of the tabs of a particular form may be completed.The display may create documents that are editable (e.g., using a wordprocessor) to allow the addition of comments or further details at anylocation within the document, or may create an image file suitable fordirect printing. Appendix C shows a sample of prose-formatted output insuch a document. Appendix D shows a sample of output in bulleted format.

Clinical records management system 102 is based on Knowledge Base 108(FIG. 1). FIG. 11 depicts further details of the Knowledge Base feature.Main GUI 1120 effectuates an efficient and smooth flow of data entry byutilizing Knowledge Base 1102. Knowledge Base 1102 houses terminologycommon to several dental specialties and rules to guide the creation ofTemplates and Forms. In building session content, the user selects aspecific Type/Sub-Category/Procedure combination matching the procedurebeing administered to patient. Template Generator 1118 dynamicallycreates a template/form using the user-selected combination, GlossaryLibrary 1212 and Rules 1214. Rules 1114 define how Glossary Library 1112is organized, associations between terms and procedures, and howProcedure-specific Forms and Templates are generated and displayed. EachForm has various tabs that display specific areas of information relatedto the specific procedure selected and covered in the form. GlossaryLibrary 1112 and Rules 1114 may be updated by an administrator via asoftware update or ‘patch’ (either locally or remotely) or manuallyusing Knowledge Base editor 1102. Knowledge Base editor 1102 may be usedby a practitioner/user to hide certain data elements in particularforms, either in the data entry or the report/letter generation. Anotheraspect of Knowledge Base 1102 involves the translation of entered datainto either text suitable for a letter or a bullet point report. Forexample, the bullet point report of FIG. 17 includes textual informationrelating to several forms, from patient general data, to a sessionexamination, treatment, and anesthesia.

Main UI 104 also includes access points for Glossary Explorer 1122 andPatient Chart Editor 1124 of FIG. 11. In addition, and as part of theuser interface, there is a method of creating and editing the GlossaryLibrary 1112 called Glossary Management Tool 1104, configuring userinterface layouts, and predefining various organizational aspects of theGlossary Library 1112 by the administrator of knowledge based clinicalrecords management system 102. Rule Editor 1106 is used to update rulesgoverning the relationship between procedures and terms, including theform and content of procedure forms and documents. Glossary ManagementTool 1104 and Ruled Editor 1106 are components of Knowledge Base Editor106 (FIG. 1). Glossary Library 112 also includes information on specifictypes of data so that multiple levels of detail may be easily navigatedby the practitioner/user. For example, in the exemplary embodiment,certain types of dental materials may be specified in a cascadingfashion so that once a practitioner/user selects a particular company,the various styles available from the company are displayed forselection, then the applicable diameters for the style are displayed forselection. Similarly, when entering a suture material, apractitioner/user may first specify the actual material being used inthe procedure and a drop-down menu of related diameters is thendisplayed.

In addition to selecting items from pull-down menus, the typing featurematches the initial few letters entered by the user with the glossaryterms relevant to that portion of the patient record. Thus, if the userattempts to type in a glossary term that is inappropriate to the currententry information of the record, no match would be found. This allows apractitioner/user to enter information that is not in the predefinedglossary if appropriate, and also provides a tool to check the spellingand appropriate use of a free text term. A further embodiment of theinvention also provides a pop-up window with a message that explains whythe typing is inappropriate to the current entry and/or suggestsalternatives that the knowledge engine determines may be the intentionof the user.

The right clicking function allows the user the ability to filter thepatient's records and present only those sessions containing informationon the user-selected category or term and within each such session onlythe information included in the selected topic. Glossary filters allowusers to limit the glossary content to a specific category or terms thatcontain a specific phrase. This reduces the time spent browsing theglossary for specific terms, and reduces the time a dentist would needto spend finding a data record relevant to the glossary term selected.

An additional aspect of the present invention relates to the AnesthesiaRecord depicted in FIG. 9. Anesthesia Record data is stored in Database114. Each Anesthesia Record contains data related to the administrationof an anesthetic modality, for example such modalities such as: localanesthesia, orally administered conscious sedation, I.V. administeredconscious or deep sedation, I.V. Administered general anesthesia orInhalation General Anesthesia. Each Anesthesia Record is broken downinto several sections, with this exemplary embodiment including: (1)Pre-Anesthesia Evaluation, (2) Monitors and Equipment, (3) OrallyAdministered Drugs, (4) Anesthetic Technique, (5) Airway Management, (6)I.V. Antibiotics Administered, (7) Anesthetic Agents Administered, (8)Vital Signs and (9) Pre-Discharge Evaluation and Status. An exemplaryembodiment of a Vital Signs page, in one form, is depicted in FIG. 10.The Vital Signs page provides information from a device monitoring atleast one of the patient's blood pressure, heart rate and blood oxygensaturation during a dental procedure, with the example of FIG. 10showing the tracking of blood pressure heart rate and oxygen saturation.However, other vital signs may be monitored and included in a VitalSigns page. Multiple Vital Sign pages may be associated with aanesthesia record, for example, a patient may have heart rate, bloodpressure, temperature, and galvanic skin response measured during ananesthesia event and recorded on separate Vital Signs pages. Theanesthesia record may be adjusted to the time duration of the procedure,showing all data on one page or zooming in a specific time block to showdata in greater size for ease of accurate viewing. Also back and forwardbuttons allow for the view to move forward or reverse to view differenttime blocks of data.

The layout of the Anesthesia Record page is determined based on theanesthesia type. Different types will hide different categories andsub-categories. Thus, each Anesthesia Record includes information aboutdosages of anesthesia delivered to the patient and data related to thepatient's response to the anesthesia. Having a distinct AnesthesiaRecord allows for disparate medical and/or dental practices to shareinformation about a specific patient's reaction to anesthesia. Anexemplary collection of Anesthesia Record screen shots are provided inFIGS. 9A-9E illustrating various aspects of the Anesthesia Record. FIG.9A represents a pre-examination record with the ability to record thepatient statistics prior to dispensing anesthesia. FIG. 9B illustratesthe charting ability to include specific medications and dosages atvarious times administered during a procedure. FIG. 9C illustrates amonitored vital sign such as blood pressure being monitored across thetime domain. FIG. 9D illustrates a similar view as FIG. 9C except withthe temporal domain being graphically compressed. FIG. 9E illustrates adischarge record relating to the anesthesia event.

The variations of the Anesthesia Record may be dynamically created oncethe modality is specified. For example, a record of Local Anesthesia mayinclude sections (1) and (6) (2); section (3) excluding anything dealingwith General Anesthesia or Conscious Sedation; section (4) includingonly Nasal Mask and Nasal Cannula choices; omitting sections (5) and(6), including section (7) and section (8) except omitting the AldreteRecovery Score and adding the notations ‘Patient discharged to escort .. . .’ As another example, an Anesthesia Record relating to OrallyAdministered Conscious Sedation may include sections (1) and (2);section (3) and section (9), excluding anything dealing with GeneralAnesthesia or I.V. Conscious Sedation, but include a list of orallyadministered analgesic agents including the times they are administered;section (4) including only Nasal Mask and Nasal Cannula choices;omitting section (5) and (6), and including sections (7) and (8). Withthe example of I.V. Administered Conscious Sedation, such an AnesthesiaRecord may include sections (1) (2) (4) (5) (6) (7) (8) and (9); section(3) excluding anything dealing with General Anesthesia; section (4)including only Nasal Mask and Nasal Cannula choices; omitting section(5) and including sections (6), (7) and (8). With an Anesthesia Recordrelating to I.V. Administered Deep Sedation/I.V. or Inhalation GeneralAnesthesia all sections are included.

Another aspect of the present invention relates to a unique set of dataand display (UI) known as the ‘PerioProfile.’ Periodontal chartinginvolves the collection of multiple parameters of site specificinformation. It can be done either one tooth at a time or more commonlyit is done one parameter at a time by making a circuit through the mouthfor each parameter. The PerioProfile allows for three different ways ofentering data: (1) a circuit approach which follows the user definedpath through the dentition to put in a single data parameter for allteeth at a time; (2) enter a single parameter on a single tooth; or (3)enter all parameters of data at once on a single tooth. FIG. 13A depictshow the user would enter a single data parameter on a single site-whileFIG. 13B depicts a periodontal charting input for all data parametersfor one tooth. The parameters entered on the screens of FIGS. 13A and13B result in the Perio chart format shown in FIGS. 12A-12D. In additionto the data values collected and included on a traditional periodontalchart, the PerioProfile may collect and simultaneously display data onsigns of inflammatory activity and produce indices for ‘Bleeding’ and‘Exudate’ activity; collect and display data on a patient's plaquecontrol effectiveness (a ‘Plaque Score’), and other strategic items ofdental and periodontal morphological data pertinent to periodontalevaluation such as including the display of normal supporting bone andextent of gingival tissue overlaying the graphical periodontal datadisplay to allow the viewing of the relationships between anatomicstructures and the extent of periodontal destruction also shown in FIGS.12A-12D.

Traditionally, the display of periodontal charting has been arrangedaround a graphic of the teeth and has utilized numbers as well asuniversally recognized symbols (for example, Roman numerals for toothmodalities). In one embodiment of the present invention, the display ofperiodontal charting is done by displaying alphanumeric data in a‘spreadsheet’ format so that data for a specific site can be readilyreviewed by scanning down a vertical column. FIGS. 12A-12D depictperiodontal charting spreadsheet screens. Additionally, this same datais display graphically around graphics of individual teeth and implantsand may include an overlay of periodontal supporting bone (FIG. 12B)and/or gingiva (FIG. 12D, both supporting bone and gingiva in FIG. 12C)to show the relationship between data items and these anatomicstructures. This comprehensive spreadsheet and graphical view ofperiodontal data is a unique design feature of this application.

While this invention has been described as having an exemplary design,the present invention may be further modified within the spirit andscope of this disclosure. This application is therefore intended tocover any variations, uses, or adaptations of the invention using itsgeneral principles. Further, this application is intended to cover suchdepartures from the present disclosure as come within known or customarypractice in the art to which this invention pertains. The followingAppendices provide examples of aspects of the present invention, whichmay be altered and adapted in various forms.

Appendix A shows a List of Type-Sub-Category-Procedure combinations fordevelopment of procedure-specific templates used in the presentinvention.

Appendix B shows a sample template used in the present invention.

Appendix C shows sample output of the present invention presented inprose format.

Appendix D shows sample output of the present invention presented inbulleted format.

1. A computer based patient records system for dental practices, withthe dental practices having a collection of general patient informationand a related collection of dental treatment information, said dentalpatient records system comprising a computer and non-transitory computerreadable storage media storing a plurality of non-transitoryinstructions for enabling operation of said computer, said computercomprising: a processor accessing the computer readable storage media,the computer readable storage media storing a plurality ofnon-transitory instructions; said plurality of instructions including:a. a first plurality of instructions for execution by the computer toobtain a particular patient record from a first collection of generalpatient information; b. a second plurality of instructions for executionby the computer to obtain dental treatment information from a secondcollection of related dental examination and treatment data that arespecific to the particular patient; and c. a third plurality ofinstructions for execution by the computer to display a plurality ofwindows on a display of the computer, with a first window displayinggeneral patient information of the particular patient, a second windowdisplaying a dental chart, and a third window displaying an editablewindow having at least one of dental examination information and dentaltreatment information related to the particular patient, said thirdwindow providing a item entry module including a procedure selectionplurality of instructions for execution by the computer to specify aprocedure and a rules plurality of instructions for execution by thecomputer to limit user item selection to a plurality of items based onthe specified procedure.
 2. The system of claim 1 further including asessions data storage storing a plurality of session, entries comprisingdental treatment and dental examination information related to aparticular patient session, said sessions data storage being accessibleto said processor, each said session entry associated with a particularpatient from the first general patient information collection and withdata in the second collection, wherein the third plurality ofinstructions populates information in the first, second, and thirdwindows based in part on the dental treatment and examinationinformation stored in a particular one of the session entries.
 3. Thesystem of claim 2 further including a session initiation plurality ofinstructions stored on the computer readable storage media, the sessioninitiation instructions for execution by a computer to allow a user tocreate a new session entry with the new session entry inheriting datafrom the most recent session of a particular patient.
 4. The system ofclaim 2 wherein the sessions data storage is configured to preventediting of a session entry except for a current session entry.
 5. Thesystem of claim 2 further including a form generation plurality ofinstructions stored on the computer readable storage media, the formgeneration instructions for execution by a computer to allow a userselection of a form from a plurality of category/sub-category forms foruser selection relating to a session entry.
 6. The system of claim 5wherein the form generation instructions further enables user editing ofthe plurality of category/sub-category forms.
 7. The system of claim 5wherein the form generation instructions are for execution by a computerto provide multiple tab data entry screens for a user.
 8. The system ofclaim 5 wherein the plurality of category/sub-category forms includecategories including at least one of: examinations, procedures, andsurgeries.
 9. The system of claim 5 wherein the form generationinstructions for execution by a computer to provide a user data entryscreens having at least one of: check boxes, pull-down selections, andfree text entry.
 10. The system of claim 5 wherein the form generationinstructions for execution by a computer to allow user creation ofdocuments having text relating to data entered on a form.
 11. The systemof claim 10 wherein the form generation instructions for execution by acomputer to allow user creation of at least one of a brief narrativetext document, and a comprehensive narrative text document.
 12. Thesystem of claim 1 wherein the third plurality of instructions forexecution by a computer to allow user editing of information displayedin at least one of the first, second, and third window.
 13. The systemof claim 1 wherein the second plurality of instructions for execution bythe computer to obtain prior documents information from the secondcollection that are specific to the particular patient, and the thirdplurality of instructions for execution by the computer to display aseparate window displaying at least one of (a) prior documents relatedto the particular patient; (b) patient alerts and modifiers informationrelated to the particular patient; (c) general health informationrelated to the particular patient; and (d) medication prescribedinformation related to the particular patient. 14-17. (canceled)
 18. Acomputer based patient records management system for dental practices,with the dental practices having a collection of general patientinformation and a related collection of periodontal information, saiddental patient records system comprising non-transitory computerreadable storage media storing a plurality of non-transitoryinstructions for execution by a computer, said computer comprising: aprocessor having access to the computer readable media, the computerreadable media storing a plurality of non-transitory instructions; saidplurality of non-transitory instructions including: a. a first pluralityof instructions for execution by the computer to obtain a particularpatient record from the collection of general patient information; b. asecond plurality of instructions for execution by the computer to obtainperiodontal information from the related periodontal collection that arespecific to the particular patient; and c. a third plurality ofinstructions for execution by the computer to display periodontalinformation including at least one of dental examination information anddental treatment information, related to the particular patient as aplurality of alphanumeric data associated with each tooth in aspreadsheet format adjacent to a graphic display of each associatedtooth.
 19. The system of claim 18 wherein the third plurality ofinstructions further enables the computer to display the alphanumericdata in spreadsheet format around graphics of individual teeth andimplants.
 20. The system of claim 18 wherein the third plurality ofinstructions further enables the computer to display graphic depictionsof teeth corresponding to the spreadsheet entries.
 21. The system ofclaim 20 wherein the third plurality of instructions further enables thecomputer to display an overlay of one of periodontal supporting bone andgingiva over the graphic depictions of teeth.
 22. The system of claim 20wherein the third plurality of instructions further enables the computerto display an overlay of both periodontal supporting bone and gingivaover the graphic depictions of teeth.
 23. The system of claim 18 furthercomprising a fourth plurality of instructions enabling the computer toallow the user to configure the procedure for entry of periodontalinformation from one of a circular entry procedure and a single toothentry procedure.
 24. The system of claim 23 wherein the single toothentry procedure involves one of entering a single value on a singletooth and entering multiple values on a single tooth.
 25. A computerbased patient clinical records system for dental practices, with thedental practices having a collection of general patient information anda related collection of dental examination and treatment information,said dental patient clinical records system comprising a computer andnon-transitory computer readable storage media storing a plurality ofnon-transitory instructions for execution by said computer, saidcomputer comprising: a processor accessing the computer readable storagemedia, the computer readable storage media storing a plurality ofnon-transitory instructions; said plurality of instructions including:a. a first plurality of instructions for execution by the computer toobtain a particular patient record from the collection of generalpatient information; b. a second plurality of instructions for executionby the computer to obtain dental treatment information from the relateddental examination and treatment collection that are specific to theparticular patient; and c. a third plurality of instructions forexecution by the computer to display a plurality of windows on a displayof the computer, with a first window displaying general patientinformation of the particular patient, a second window displaying adental chart, and a third window displaying a dental clinical record,said dental clinical record being editable in said third windowincluding selection of a procedure and having at least two of thefollowing template entries selectively accessible according to aselected procedure: examination information template entries, treatmentinformation template entries, radiographic information template entries,laboratory information template entries, anesthetic information templateentries, all such template entries related to the particular patient andselected procedure, said template entries being selectively displayed insaid third window based on predetermined rules.
 26. A computer basedpatient clinical records system for dental practices, with the dentalpractices having a collection of general patient information and arelated collection of dental examination and treatment information, saiddental patient clinical records system comprising a computer andnon-transitory computer readable storage media storing a plurality ofnon-transitory instructions for execution by said computer, saidcomputer comprising: a processor accessing the computer readable storagemedia, the computer readable storage media storing a plurality ofnon-transitory instructions; said plurality of instructions including:a. a first plurality of instructions for execution by the computer toobtain a particular patient record from a first collection of generalpatient information; b. a second plurality of instructions for executionby the computer to obtain information from a second collection ofrelated dental examination and treatment data that are specific to theparticular patient; and c. a third plurality of instructions forexecution by the computer to display a plurality of windows on a displayof the computer, with a first window displaying general patientinformation of the particular patient, a second window displaying adental chart, and a third window displaying an editable window having atleast one of dental examination information and dental treatmentinformation related to the particular patient, said third window havingat least one editable field restricting user item selection to apredetermined glossary of items dependent on predetermined rules and thesaid at least one of dental examination information and dental treatmentinformation related to a particular patient.